[Previous] [Next] [Index] [Thread]

Re: Java security problems (fwd from Risks Digest #17.77)

[Fairly cogent analysis of description attack deleted.]
>Why is this attack possible? 
>----------------------------
>
>There are two reasons why this DNS Spoofing attack works: 
>
>	1)  It's relatively easy for someone to advertise false IP 
>	    addresses.   That is, it's relatively easy for someone
>	    to run their own domain name resolver.    
This is really incorrect. The problem is not in the DNS
but rather in Java itself. While it is true that the DNS is
radically insecure and that spoofing is easy, this is not a spoofing
attack. [As I'll discuss later, however, spoofing could be used
to defeat the obvious defense against this attack.] 

Let's review how the DNS works. It's a distributed database with
domain names as lookup keys. The world of possible domain names
is divided hierarchically with different pieces delegated to different
parties who can further delegate chunks of that address space, but
who are also permitted to make records in that space. For instance,
the Internic has delegated terisa.com to me, which means that I
am responsible for serving records with lookup keys that end in 
".terisa.com." That is to say that I am entitled to answer queries
for any host in the terisa.com domain.

Nearly all DNS security measures are concerned with providing integrity
and assurance for these relationships. [See in particular 
draft-ietf-dnssec-secext-09.txt] (The rest are concerned with
preserving the integrity of the servers themselves against breakins.)
That is to say that they provide assurance to the resolver
(the machine trying to perform a lookup) that the answering server
is actually the machine entitled to answer that query, and that that
server attests to that answer. They are explicitly not concerned with
providing the integrity of the answer itself beyond the fact that
the authorized server says so. To state it bluntly, the authorized
server could be lying. (Which is the case we have here.)

Note that we still haven't said anything about IP addresses. Actually,
there are a number of kinds of records that it can serve, IP addresses
(what are in the DNS called A records) are only one kind, and are
what people usually think of, but it helps to bear in mind that there
are other kinds of records, including MX records (which provide the
preferred mail exchanger for the machine) and HINFO records which
tell what kind of operating system and hardware the host associated
with the record has. I mention this to show that at least in some
instances DNS security can at best be concerned with is to prevent
unauthorized parties from answering for domain space I control. While
one might believe [I'll get to this in a minute] that I could be stopped
from advertising A records for IP networks I don't control, it's
ludicrous to believe that I could be stopped from saying the 
foobar.terisa.com (a machine I have every right to talk about) is
a Mac when it's really a PC.

Now let's talk about IP addresses and get to the specific thing 
that Marianne says is the cause of the problem:
I am the owner of a given chunk of domain name space. I have been
delegated this space by the Internic. I am also the owner of a given
chunk of IP address space. I have been allocated this address space
by my provider. Now, there's nothing stopping me from allocating
A records in my domain name space that point to pieces of IP address
space that I haven't been allocated. For instance, I could register
ftp.terisa.com as pointing to 192.100.58.3, thus pointing it at
ftp.eit.com.

Now let's see how this can be used to attack Java. 
Java's 'phone-home' restriction is apparently enforced by
fetching the A record(s) associated with the domain name from
which the applet came and then comparing those A record(s) with
the IP address to which the applet is attempting to connect.
So, the attacker serves up two A records, one for the actual
machine name and one for the target machine. The applet looks
up the A records, finds that one matches, and so accepts
both. Consequently the applet (working in cooperation with 
the attacker's DNS server) can now make a connection to 
any machine on the net. A particular interesting form of this
is to use it to attack machines inside the security perimeter
where the applet is running.

This sounds bad, but consider: maybe I'm at the end of a slow link
and EIT is is providing ftp service for me. (This is extremely
common for the Web, because it permits garage shops to provide
good web service without paying for fast links.) Now, clearly EIT
isn't going to allocate the IP for my FTP server out of my IP space.
My traffic would never get routed to them, then. They're not
my provider. (As it happens, they do _share_ a provider with me,
but they might not.) No, they allocate it out of their address space.
So it's not always true that people serving A records to IP addresses
out of their IP space are malicious, nor is it always undesirable.

Not only is this not undesirable, it's unstoppable. Even assuming
that the Internic had a map of who has authority over every IP number
available (which, post-CIDR, they don't) they would have to recursively
examine every delegated DNS server on the planet to make sure that noone
was serving bogus records (and then somehow shut them down,
which they don't have authority to do anyway.)

Don't get me wrong, though, there are ways to make your system
resistant to this. In fact, they are common practice. You see,
it's not only possible to map names to IPs, it's also possible
to map IPs to names. There is a special domain delegation, the
in-addr.arpa domain which is used for this purpose. When the
Internic (or your provider) reserves IP space, they delegate
to you the corresponding section of the in-addr.arpa domain,
which you are expected to populate with the domain names of
hosts. Looking up the domain name of a host from it's IP is typically
called a reverse lookup.

Now let's consider how reverse lookups can stop this sort of attack:
The security module would perform the forward lookup for attacker.com
as before and recover the (legitimate) address 1.2.3.4 and the (bogus)
one 4.5.6.7. It would then perform reverse lookup for 1.2.3.4 and 
get attacker.com and for 4.5.6.7 and get victim.com. Since the
forward and reverse records for 4.5.6.7 don't match, it should
refuse to make the connection. Note that this tactic is quite well
known and used in (for example) Wietse Venema's TCP Wrappers package
to detect the reverse form of this attack. Now it's true that
reverse resolution information is often not available, but it
should be. The popular ftp.uu.net FTP site, for instance,
refuses service to people who don't serve reverse name resolution.

Now, a real spoofing attack can be used to defeat this. The attacker
would forge the reply for the reverse lookup for 4.5.6.7 and return
attacker.com. DNS security is intended to prevent this from happening.
But this isn't what we're talking about here. As far as I can tell
simple reverse name resolution would have solved the problem. 
(Heck, just comparing the IP address from the original HTTP fetch
to this connection would solve the problem without involving the 
DNS at all.)

Sorry to have gone on at such length, but I wanted to present
enough background to justify the comments that are about to follow.

Marianne writes:
>The right solution for this problem is to make the Domain Name Service
>more secure.  It shouldn't be so easy for anyone to advertise false
>names or false addresses.

This simply isn't so. The DNS is operating precisely as it's supposed
to. The problem is simply that the programming in Java was broken. I'm
assuming that Java doesn't do reverse name resolution because otherwise
this sort of attack would be much more difficult possible. DNS 
spoofing is straightforward, but not nontrivial (I can speculate on why,
but I truly hope it's not just they they didn't know about it.). No
DNS security measures that I know of will in general protect against 
lying servers in a reasonable way (This is a special case because there
is a cross-check under separate administrative control.)

The surface risk here is obvious: don't rely on security-critical 
information from parties whom you don't trust. But there is another
risk here, which I'd like to talk about a bit, which is confusing 
authenticity and integrity with accuracy. In particular, Marianne
refers to this as a DNS spoofing attack, which I think confuses the
issue because the information is coming from the source which is
absolutely legitimate. It's simply lying. It is often possible to
provide services such as message integrity, data origin authentication,
etc. with technical means, but providing accuracy is often much harder,
even when the source of the data is trustworthy, but even moreso when,
as in this case, the source is malicious. 

-Ekr
Follow-Ups: